home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / www_talk.arc / 000294_raisch@cthulhu.control.com _Tue Nov 3 18:32:41 1992.msg < prev    next >
Internet Message Format  |  1992-11-30  |  3KB
  1. Return-Path: <raisch@cthulhu.control.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA13567; Tue, 3 Nov 92 18:32:41 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA01614; Tue, 3 Nov 92 18:44:49 +0100
  6. Received: by control.com (4.1/Spike-2.0)
  7.     id AA04629; Tue, 3 Nov 92 12:42:31 EST
  8. Date: Tue, 3 Nov 1992 12:32:24 -0500 (EST)
  9. From: Robert Raisch <raisch@cthulhu.control.com>
  10. Subject: Re: question and answer, style guide? 
  11. To: Tim Berners-Lee <timbl@www3.cern.ch>
  12. Cc: Edward Vielmetti <emv@msen.com>, www-talk@nxoc01.cern.ch
  13. In-Reply-To: <9211031230.AA01398@www3.cern.ch>
  14. Message-Id: <Pine.3.03.9211031222.O272-b100000@cthulhu.control.com>
  15. Mime-Version: 1.0
  16. Content-Type: TEXT/PLAIN; charset=US-ASCII
  17.  
  18. On Tue, 3 Nov 1992, Tim Berners-Lee wrote:
  19.  
  20. > >  I am not sure yet whether you can
  21. > > design something that's optimally designed for a 24x80 ascii screen
  22. > > and also for paper (probably not) but at least it'll be usable in both
  23. > > contexts.
  24. > 
  25. > 
  26. > Do you feel that
  27. > 
  28. >  (a) you need more variety of tags, or that
  29. >  (b) the 24x80 representation of the existing tags is suboptimal, or that
  30. >  (c) the task is impossible by its nature -- you must rewritethe document.
  31. > 
  32. > If (a), we should take that into account for HTML extentions.
  33. > If (b), you can change the DefaultStyles.c built-in style sheet
  34. > If (c), I agree. In principle. But In practice we need to comprompize.
  35. > 
  36. >     Tim
  37.  
  38. The main goal of SGML and one which I believe it meets reasonably well is
  39. the seperation of display issues from content issues.
  40.  
  41. Presentation issues can only be guessed at, never known.
  42.  
  43. Only by decoupling the presentation of information from it's organisation
  44. can we hope to develop useful tools. (IMHO)
  45.  
  46. A simple example might be the rendering of a list.  How would you do it?
  47.  
  48. A "LIST" is nothing more than a collection of items.  There should be no
  49. inherent assumptions as to how it might be rendered.
  50.  
  51. I could conceive of a block of text containing the first element, and an
  52. indication that there were more elements available (via some user
  53. interaction).
  54.  
  55. Or even the complete collapse of the list into just an indication of it's
  56. existance, (a "jump").
  57.  
  58. The point should be (IMHO) that the rendering decision should ALWAYS be
  59. left to the client.  Any rendering-centric portions of HGML should be
  60. replaced by more general constructs.
  61.  
  62. Perhaps what we need is a WG to design the next generation of HGML?  Is
  63. there such a beast already?
  64.  
  65.         </rr>
  66.  --
  67. I hate 3 things: Ignorance, Poverty, and Moving.  Well, maybe not in that order.
  68.  
  69.